This invention relates to wireless networks that support push-to-talk (PTT) group calls and more specifically to the ability to bridge support for such calls between two different types of wireless networks. For example, a PTT group call is supported among members of a group where some members of one group are in a public safety wireless network and other members of the same group are in a commercial wireless network.
PTT in Public Safety Wireless Networks
Wireless networks have been in use in the public safety sector, (police, fire fighters, emergency workers, etc.) for a long time. In the United States, the standard of public safety wireless network is the APCO (Association of Public Safety Communications Officials) Project 25 (P25) Systems whose specifications are the responsibility of the Telecommunications Industry Association (TIA), standard committee TR-8. The P25 standard is an international standard with system deployed in over 40 counties.
FIG. 1 shows an embodiment of a high level architecture of a P25 system. The local network may consist of a number of base stations 110 and 120, referred to as sites in P25 terminology. Subscriber wireless communication devices 101-104 are connected to the base stations through the air interface. The base stations are connected to a collection of controlling modules referred to collectively as the radio frequency sub-system (RFSS) 126. In P25, two relevant functional modules are the call control module 122 which handles call signaling, and the media control module 124 which deals with the forwarding and processing of media (e.g. voice) traffic. Attached to the RFSS are peripherals such as dispatch console 128, databases 130, data terminals 132, and gateways 134 to other networks such as the public switched telephone network (PSTN) 136. An Internet Protocol (IP) network 138 couples the RFSS 126 to other RFSS's.
Group Calls and Push to Talk
One application for a public safety wireless network is a group PTT call, i.e. a call in which one member of the group can speak to all other members simultaneously. For example, all police officers on patrol could constitute one group. In order to facilitate communications in an orderly manner, a floor control mechanism is needed to arbitrate who should speak in the event two and more members request to speak at the same time. As is known, a PTT user who wants to speak to the group will push a button on the person's handset. A message would then be sent to the RFSS which will arbitrate all the talk requests and either grant or deny each request by sending a response back to the requesters.
The Inter RF Sub-System Interface
The public safety sector has recognized the need of connecting different RFSS together to form a larger network with a much larger coverage. Based on this need, the TIA TR8 committee has developed such a standard, referred to as the Intra-RF Sub-Systems Interface (ISSI). This specification is based on the IP for the transport of information. The call signaling protocol is based on Session Invitation Protocol (SIP, RFC 3261), while the voice traffic and push-to-talk control messages are carried through the use of Real Time Protocol (RTP), RFC 3550). The ISSI specifies the connection between the RFSS's. The over the air interface protocol is specified by another suite of standards.
With the ISSI, a group can span multiple RFSS's. One RFSS would be designated the home RFSS which will manage all the activities of the group. The floor arbitrate function of the group also resides at the home RFSS. The non-home RFSS's are referred to as serving RFSS and are connected to the home RFSS through RTP. Members of a group do not need to at the home RFSS; they can roam to other RFSSs. When a user of the group requests the floor, i.e. permission to talk to the other group members, the serving RFSS will forward the request to the home RFSS using the ISSI protocol. The home RFSS will arbitrate any received requests and award the floor to a “winning” user. In addition to floor arbitration, the home RFSS also receives voice traffic from a serving RFSS and forwards it to other RFSSs. Specifically, the ISSI supports the following functions for group calls.
Group registration of a serving RFSS to a home RFSS: When a user at a serving RFSS indicates that it would like join a group, the serving RFSS will register the user with the home RFSS indicating that there are one or more users at its location joining the group. The SIP REGISTER message is used to accomplish this registration process.
Call control: Voice traffic as well PTT control messages are conveyed using RTP. ISSI specifies procedures to set up RTP connectivity between home RFSS and serving RFSSs. The SIP INVITE message is used to effect the RTP set up. In order to conserve network resources, after an extended period of inactivity, the home RFSS may tear down the RTP connections between it and the serving RFSSs. During this period, the serving RFSSs remain registered with the home RFSS. When the call becomes active again, the home RFSS or the serving can trigger call set up to re-establish the RTP connectivity again.
PTT-control: ISSI provides a set of control messages to support push-to-talk. These messages are encoded as part of the RTP messages.
Voice traffic: Voice traffic is also carried as part of the RTP payload. RTP connectivity must be established before PTT control messages and voice traffic can be sent between the home RFSS and the serving RFSSs.
PTT Control in ISSI
ISSI supports the following PTT control messages.
PTT-transmit-request: A message sent from a serving RFSS to the home RFSS requesting the floor on the behalf of a user.
PTT-transmit-grant: A message sent by the home RFSS to a serving RFSS granting a request from that serving RFSS
PTT-transmit-deny: A message sent by the home RFSS to a serving RFSS denying a request from that serving RFSS
PTT-transmit-start: A message sent by the home RFSS to all serving RFSS, except the serving RFSS that has been granted the floor, indicating that the floor has been grant to a user at another RFSS. These RFSS's should be prepared to receive traffic.
PTT-transmit-wait: A message sent by the home RFSS to a serving RFSS which has just requested the floor. This message indicates that the home RFSS is processing the request but the processing may take some time such as when enhanced functions are required.
PTT-transmit-mute (and PTT-transmit-unmute): These messages can be sent by all RFSS to mute (or unmute) a transmission temporary such as because of resource problems.
PTT-heartbeat and PTT-heart_query: These messages ascertain the RTP connectivity between RFSSs.
FIG. 2 is an illustration of a PTT call flow over ISSI. In FIG. 2, RFSS 200 is the home RFSS of a talk group. Connected to RFSS 200 are serving RFSS 210, 220, and 230. Users (SU) 212, 222, and 232 are connected to these RFSS's respectively. In this example, we assume that RTP connectivity between the home RFSS and the serving RFSS has already been set up. The sequence of events is as follows.
The users of SU 212 and SU 222 both want to speak to the floor. They press a button at the handset at about the same time. By pressing the button, the handset will generate a Group-voice-request (GRP_V_REQ) message to their respective serving RFSS (210 and 220) over the air interface. They are shown as message 1. and 1′.
Serving RFSS 210, upon receiving the GRP_V_REQ message from SU 212 will generate a PPT-transmit-request message to the home RFSS. The PTT message is one of the push-to-talk control message encoded as a RTP packet as specified in the ISSI specification. We assume that SU 212 is the only SU to request the floor at RFSS 210. If there are more that one SU at RFSS 210 requesting the floor, RFSS 210 will determine a local winner, based on the priority of the request as well as the local policy. The PTT-transmit-request message includes the identity of SU 212, the subscriber requesting the floor. Similar events take place at RFSS 220. The PTT-transmit-request messages are shown as message 2. and 2′.
The home RFSS, upon receipt of the two PTT-transmit-request messages, from RFSS 210 and 220, will decide who would win the floor. In this example, we will assume that SU 212 is the floor winner. Upon deciding that SU 222 is the floor winner, the home RFSS 200 will:
Send a PTT-transmit-deny message 3 to RFSS 210 informing it that its request for SU 212 has been denied.
Send a PTT-transmit-grant message 4 to RFSS 220 indicating that SU 222 has been awarded the floor.
Send to PTT-transmit-start message 6 to all RFSS except RFSS of the floor winner, RFSS 220.
Both the PTT-transmit-grant and PTT-transmit-start messages contain the identity of the floor winner. Both messages, upon arrival at the serving RFSS, will cause the generation of Group-voice-grant (GRP_V_GRANT) messages 7. and 7′. over the air to all members of the group connecting to the RFSS. Through these messages, other members of the group are informed that SU 102 is awarded the floor and that each should prepare to receive speech from it.
Losing Audio and Early Audio
When two users (UE1 and UE2) request the floor at the same time, only one of them (e.g., UE 1) will be granted the floor. However, this does not imply that the call from UE 2 is less important. Both calls may well be emergency calls. Most public safety networks support the concept of “losing audio”. In the above example, UE1 is awarded the floor. Its audio stream, referred to as preferred audio, will be the audio stream that will be audio stream that will be broadcasted over the air to all subscribers. UE 2 is denied the floor but has the option to send its audio stream to the server anyway. The server will forward this audio to a pre-configured set of special stations such as recording machines and dispatch stations. In this way, audio from UE 2 can be listened to by these special stations. Most of the special stations are connected to the network via wire line links and usually have the ability to handle multiple inputs. Audio streams from users that are not the floor owner are referred to as “losing audios”.
Another feature in public safety PTT applications is the concept of early audio. In early audio, a user is allowed to speak before his or her handset receives the floor grant from the server. Early audio can occur in a number of ways. First, some early legacy systems lack centralized PTT arbitration control. In these systems, users can just talk without requesting the floor first. Secondly, even in systems with centralized floor control, the floor request or the floor grant may be lost in the network. After some wait, the user is permitted to speak even without an explicit grant as it may be a critical call and should not incur more delay. Both losing audio and early audio are features supported by ISSI.
PTT in Commercial Wireless Networks
PTT has also generated a lot of interest in the commercial wireless networks. Applications are diverse ranging from a small group of friends in a conference PTT call determining where to meet for lunch, to communications for a fleet of cab drivers in a metro area. There are a number of proprietary solutions and standards being developed for such applications. One standard is the Push to Talk over Cellular (POC) standard from the Open Mobile Alliance (OMA). This standard is usually referred to as the OMA-PoC suite of standards.
In OMA-PoC, subscriber handsets (referred to as UEs) are connected to a server that supports the PTT function. This server usually referred to as the PoC controlling server (PTT server for short). In OMA-POC, SIP is used as the call signaling function to establish RTP connectivity between a UE and the POC server. Voice traffic is encoded as RTP packets. When establishing an RTP connection, an associate connection, known as Real time Control Protocol (RTCP) is also being simultaneous set up (i.e. RTP and RTCP are set up in pairs). One use of RTCP is to convey performance statistics from a receiver to the source of a media stream. Also, a user can use RTCP to carry other application data. OMA-POC uses RTCP as the method to convey PTT control packets. This protocol is referred to as the Talk Burst Control Protocol (TBCP). TBCP supports the following basic messages between the UE and the POC server:
TB-Idle: from the server to all the UEs indicating that the floor is idle.
TB-Request: from the UE to the sever requesting the floor
TB-Grant: from the server to a UE granting the UE's request for the floor.
TB-Deny: from the server to a UE denying the UE's request for the floor.
TB-Release: from the current speaking UE to the server indicating that it has finished.
TB-Taken: from the server to all other UEs indicating the floor has been granted to another UE.
TB-Revoke: from the server to the current floor owning UE indicating that the its floor ownership is revoked
TB-Disconnect and TB-Connect: These messages are used to establish and to tear down TBCP connectivity.
TB-Request-queue-status-request and TB-Request-queue-status-request: These messages are used to support a queued system, which will be described later.
In the OMA-POC architecture, there is another component, referred to as the participating server. A number of UEs can be connected to a participating server which, in turn, is connected to the PoC control server. It provides more flexibility in call control configuration. As far as push-to-talk control (TBCP) and media traffic is concerned, a participating server just acts as pass through.
Queued and Non-Queued System
When a number of UEs (e.g., UE1, U2, and UE3) requesting the floor at the same time, the server would grant the floor to one of the requesting UE (e.g., UE1) the floor. In a queued system, the server will retain the requests from other UEs (e.g., UE2 and UE3) in its request queue. When the current floor owner (UE1) finishes and yields the floor, the server will then award the floor to a UE in its request queue (UE2, UE3, and other new arrivals). The TB-Request-queue-status-request message is used by an UE to request the status of its request in the request queue. In a non-queue system, the server would not retain a request queue. When a UE has made an unsuccessful floor request in a non-queue system, it has to send a new request again when the current floor owner yield the floor.
Contrast Between Networks
Commercial wireless networks have a much larger footprint than public safety wireless networks (PS-network). New public safety wireless networks are expensive to create. As commercial wireless network technologies begin to introduce PTT capability into their systems, it may be advantageous for public safety organization to consider deployment of commercial network technologies into their network as commercial wireless technologies tend to be cheaper based on economy of scale and progress in a rapid rate. However, there are problems to be overcome before a public safety organization can either deploy new services in a commercial wireless network or integrate an existing PS-network with a commercial wireless network. The current PS-networks must be interoperable with the commercial wireless technology. Further when interconnecting a PS-network with a commercial wireless network, all the needed public safety features, e.g. a PTT group call, must be supported in the commercial wireless network. Other notable features in public safety, e.g. emergency override and the support of “losing audio” and “early audio” should also preferably be supported in the commercial wireless network.